-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Add support for GitHub actions #95
Conversation
README.md
Outdated
@@ -16,7 +16,7 @@ remove deployment platforms, or test with a different suite. | |||
## Features | |||
* Python-centric skeletal structure with initial module files | |||
* Pre-configured `setup.py` for installation and packaging | |||
* Pre-configured Window, Linux, and OSX continuous integration on AppVeyor and Travis-CI | |||
* Pre-configured Window, Linux, and OSX continuous integration on AppVeyor+Travis-CI and/or GitHub Actions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am all for dropping Travis and VERY much for dropping AppVeyor. Go for it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall I remove them as part of this PR or should this be in a separate PR (also merged to dev
) for extra clarity?
I have added Windows support by simply forcing |
That seems to work! Look here for a similar setup: https://github.com/openkinome/kinoml/pull/5/checks |
By the way, do we want to update the CI on this repo too so it uses GH Actions? |
This looks really great, let me try this out in a few of our packages and see how it goes. I would vote to changing the repo's CI in another PR. |
This is my pass at the YAML: https://github.com/MolSSI/QCElemental/pull/172/files |
{% if cookiecutter.dependency_source != 'Dependencies from pip only (no conda)' %} | ||
eval "$(${CONDA_EXE} shell.bash hook)" && conda activate test | ||
{% endif %} | ||
codecov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW this doesn't work without a token. I recommend using their image
- name: CodeCov
uses: codecov/codecov-action@v1
with:
token: ${{ secrets.CODECOV_TOKEN }}
file: ./coverage.xml
flags: unittests
yml: ./.codecov.yml
Add --cov-report=xml
to the pytest line as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed and was about to ask! Thanks!
shell: bash | ||
if: startsWith(matrix.os, 'windows') | ||
run: echo "::set-env name=CONDA_EXE::$CONDA/Scripts/conda.exe" | ||
{% endif %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do look through this YAML, a lot of this simply isn't needed: https://github.com/MolSSI/QCElemental/blob/827e3e6faf9ba08f327bafff87e893b8f8d559fa/.github/workflows/CI.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So conda
is in PATH
? Cool!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is not applicable to Windows! Shall I revert the changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add it to the path for Windows only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed this discussion and there seems to be some problems with path modification. I'll try to use condabin
instead, and see if that works better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, looks like conda
is only in PATH
in Ubuntu. I keep thinking that the CONDA_EXE
approach is the cleanest although it requires one more setup step.
We could use a single step too:
- name: Set-up conda
run: |
if [ "${{ matrix.os }}" != "windows-latest" ]; then
echo '::set-env name=CONDA_EXE::${CONDA}/bin/conda'
else
echo '::set-env name=CONDA_EXE::C:\Miniconda\condabin\conda.bat'
fi
shell: bash
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we could add a conda function in this manner? If not I would recommend something simple so that further lines can do eval '$CONDA_INIT'
or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best thing would be modifying the bash_profile
/bashrc
to autostart conda for us (but we should still run conda activate test
once the environment has been created, although we could check for test
existence and activate that instead?), but I think that default bash
interpreters in GitHub are configured to ignore profile files, so we would need to define a custom shell
in each step. I am not aware of any option to override the default shell
for all steps - if that's possible, it'd be the best way. Anyway, shall I try with the bashrc
+custom bash shell
approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've tried this route but it's not pretty at all because we would need to always specify shell: bash --noprofile --rcfile conda_init.sh -i -e -o pipefail {0}
. I find that very confusing and hard to reason about.
Instead, I have opted to create this auxiliary script and call it at the beginning of each step:
- name: Install package
shell: bash
run: |
. devtools/scripts/initialize_conda.sh
python -m pip install . --no-deps
conda list
That way the intention is clear and the initialization code is easier to maintain. Would you prefer this approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went ahead and added the script in the last commit.
On the codecov line add |
Oh, due to a WSL bug, my commits are dated as 4 days old. Next ones should be ok, though. Sorry for the confusion! |
Shall we try @dgasmith's suggestion that this gets merged into a |
I've read through all of this, what are the things we are waiting for, @jaimergp? By my thinking, we just need to change the target branch this is being merged in to? Or is there something else I am missing? |
We have been using GHA for a while now in several repositories, and have accumulated some knowledge on how to use it. I have some fixes to add here as well (macOS permissions, for example). I'd say I can add the fixes here, and then we merge to dev. Additional features could be targeted in separate PRs. What do you think? |
Considering that we are using CookieCutter now for MolSSI Education, I would ask that the GHA change be put on a branch or that GHA is listed as an option in CookieCutter set up (travis-ci or GHA) |
I like the idea of being able to select either travis-ci or GHA until we can make sure that the GHA works robustly for a variety of people. At some point, we can just make GHA the default once folks are happy with it (and hopefully the MolSSI Education program can switch over at that point too). |
@jaimergp Is it possible for you to make your changes here that you mentioned, then once you're done, I'll come back in and make it an option to either use travis or GHA as part of the cookiecutter? That way we can get this in without having to worry about a separate branch, and we can mark the GHA experimental while we work out kinks. |
Added to my list. I'll add them some time this week! |
Big fan of:
Seems to work very well these days. |
@Lnaden, I have added the last changes I was talking about. Namely:
Todo:
|
Awesome. I think this has come together fantastically. There is just one small change I would like to request: I am thinking we should make the travis (or +appveyor) default first until we fully debug GHA. Does that work for you? Things I intend to do after we merge:
|
That's an excellent point, yes! This shouldn't be the default just yet. I'll add the changes now. |
Great. Once those are in, I think we can merge this. I'll keep the 1.3 until we get GHA stable, then move to 2.0 |
Hm, I am thinking that maybe we should label GH Actions as experimental in this early stage? Like this: "continuous_integration_provider": [
"Travis",
"Travis+AppVeyor",
"GitHub Actions (experimental)"
], What do you think? |
I think thats a great idea. Makes it very clear this is a work in progress. |
Ok, let me add that before you merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ready to merge finally. Thanks for all the work in making this ready!
I'm getting one more pair of eyes to look over this before I hit merge just in case I missed something obvious, but I'm investigating the nested/chained GHA in the meantime. |
This PR adds preconfigured support for GitHub Actions, following conversation in #90.
To do
openkinome/kinoml
$CONDA
. Test this is true and functional.${{ variable }}
) that interferes with cookiecutter's Jinja processing. I think we just need to escape this on the unprocessed YAML to make the tests pass.