|
I think I’m now done with CI stuff, the GitHub Actions builds now save all their tapfiles into an artifact (downloadable as a zip-file, kept by GitHub for 90 days). Ralph you might want to take a look at my recent changes in case any are worth including in
the ci-scripts module examples.
- Andrew
On Dec 26, 2020, at 9:15 AM, Ralph Lange via Core-talk < core-talk at aps.anl.gov> wrote:
On Wed, 23 Dec 2020 at 19:42, Johnson, Andrew N. < anj at anl.gov> wrote:
I just set “Custom configuration .yml file
name” to empty in the epics-base-3 project UI, and it subsequently picked up and used a change I then committed to the file on the 3.15 branch! The doc’s say that the filename “.appveyor.yml”
is supported as is, and apparently leaving it blank made it do the right thing (we still have the “branches/only” whitelist in the file, I also added the regex /R3\.15\.\d+.*/ to that).
That was the original state and didn't work as expected when I tested it a few weeks ago.
Note that the important point is that the epics-base-3 project should *not* build commits to the 7.0 branch and vice versa. For me, it was always all projects building all branches - unless I was using the gists.
Aargh, and of course I didn’t check the epics-base-3 account after pushing the 7 change…
I have just followed Michael’s suggestion and renamed the file, although without really thinking about how to handle pull requests. The epics-base-3 account should now only build branches that have a file named .appveyor/epics-base-3.yml and
the epics-base-7 branch uses .appveyor/epics-base-7.yml so the filename in the new .appveyor directory matches the account it configures. The 3.15 branch is building now; I’m about
the push the 7.0 branch to match.
- Andrew
--
Complexity comes for free, simplicity you have to work for.
--
Complexity comes for free, simplicity you have to work for.
|
