-
Notifications
You must be signed in to change notification settings - Fork 81
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
Add Login Action #1
Conversation
Hi @Greg-Hamel! Thanks for the feature, it was in the "backlog of tasks" for me too 😉. Unfortunately, I ran into some issues when building new versions from Action. It's related to the maximum
(Did some research why it worked on other vendors, despite having the same inotify) So unfortunately, until this is resolved either by Expo or GitHub Actions, the most crucial command (publish) is blocked. I'm at the conference April 4th, I can try to bring it to their attention. Again, thanks for this, really appreciate it ❤️ |
I'll add some other files to keep the sturcture in sync with cli 😄 (just the basic stuff like license etc) |
Thanks for the quick merge, as for the problem with inotify, I haven't encountered the same issue... yet. Maybe our Actions are a tad different, mine is still in its early stages (not a whole lot of actions yet). My publish seems to work correctly, and I feel like I took it directly from one of your test repos. Here is the log from the publish part: And of course, the main.workflow
|
Wow! That looks awesome! Let me try to set up a basic project and see what happens. It might be fixed already then! 😄 Thanks for this! |
Dude, you are right! It's working now without the |
@byCedric, my pleasure! Glad I could help you help me! Keep up the great work 🏆 🎉 |
You too @Greg-Hamel 🚀! I just updated the master, consider this as a pre-release. I'm going to add the 3 build commands as separate actions, and then it's ready. One change to notice is that I've moved the |
We ended up actually hitting the inotify limit in the last day or so. First thing we did was try to change it within the Docker context. This doesn't seem to be supported at the moment, and as the comment from GitHub suggest might not be for a while... You can see the attempted fix: master...mgibeau:master. This still returns 8192 even after attempting to change it. What fixed it (for now) though, is to add an extra step during the pipeline to prune the
Hopefully, this might help someone else who stumbles upon that problem :) |
@mgibeau Thanks a lot! That's something I didn't know for sure 😄 I have been in contact with the GitHub support team, they said they made a case for the developers. But they couldn't provide any ETA or status update, if and when the inotify is getting fixed. There are some other actions hitting this limit too, unfortunately. But I think this is a great workaround, thanks! ❤️ |
@byCedric,
Thanks a lot for putting efforts in trying to get actions available for the expo-cli. I've been looking at getting those implemented, but lacked the motivation/knowledge to get started.
During my tests of your action, I've been having lots of problems getting a successful and censored login with the expo-cli. I'm sure you are still working on it as I can see that your docker hub has a few recent changes.
I've come to realise that in order to use the SECRETs without them returning 'Filtered', they need to be use by the
entrypoint.sh
directly and not through arguments. I was inspired by the how the docker/login action works.The login action in this PR seems to work flawlessly in the different tests I've made, even censoring the SECRET correctly.
Let me know what you think!
Cheers,