log-comments-7-22.csv

actions_eng_satisfaction_survey.comment
I think that the log output is fairly difficult to read\, not only because displaying the log is fairly slow for huge log outputs\, but it is also very small (only around 30 lines of code are displayed on a 1440p monitor).\r\n\r\nSince I have mostly migrated from Travis (because GitHub Actions is far superior in terms of Selenium Browser Tests)\, I got used to the display of Travis for the log output\, where all output is displayed and loaded asynchronously. Furthermore\, unimportant lines are collapsed (e.g. git checkout)\, so that the first 100 lines are skipped.
UI is dreadful\, it's not easy at all to do trivial things (e.g. see a log of what happened and when)
I like providing binaries for all builds\, keeping only the latest.  Currently\, I'm doing this by publishing a pre-release after every build.  The links to these builds are fixed since the tag is always the same\, which makes it easy to put a link on the top-level README.md to provide access to the latest binary.  However\, this sends an awful lot of notifications..\r\n\r\nWhile using build artifacts can provide a similar functionality\, the double-zip problem is annoying\, folks that want to download them have to be logged in\, and it makes it more difficult to link to them.
The log output is not as good as GitLab - usually it only loads after the action is finished running
Documentation is hard to read and understand when quickly trying to find a thing. I don't have the time to dig through all the docs to find the correct thing I need.\r\n\r\nAlso\, understanding why a build has failed or not working as expected is also difficult. A sandbox to log environments and stuff like that would be cool. Variables in the docs need their expected results listed side-by-side.
If I open a running task\, only the logs printed afterwards are shown. It would be nice to be able to see the log lines already printed.
When using services and docker containers is not obvious how to check for failures in linked services. For example is difficult to see the logs of connected services that failed to start.
gh-pages package suppresses many errors caused by packages it depends on. For example\, if git push is failing under the hood because of some refs on the remote\, this package would sit silently without outputting any logs or shell warning.
Scrolling through the logs isn't a very pleasant experiences (windows within windows is a terrible UI) and cut and paste doesn't work from the log window for more than one screen's worth of data.\r\n\r\nA command line interface for reading the logs from a failed action or an easy click to say open this log in a new window would help a lot.\r\n\r\nGitHub actions are great - they've replaced Travis\, CircleCI\, Appveyor and Docker Hub builds for me\, so only one set of YAML syntax to keep in my head.
the UI is slow when showing the progress. it is also hard to see the log because the view-able space is too narrow.  
Navigating the build logs while the build is running is very sluggish and takes forever to load etc.
There are 3 big things we need that are top-of-mind to completely ditch TeamCity and go all-in on Actions:\r\n\r\n* Ability to run Linux containers on a Windows agent\, for example\, to test .NET Core code on both Windows and Linux that has a dependency on RabbitMQ\, which does not provide a WIndows container image.\r\n* Better UX for surfacing failed tests (i.e. with a TRX output) than digging through a text log.\r\n* The ability to manually promote a specific commit (i.e an alpha/beta release) to a different workflow to create a production release.
Everyone who looks at a broken build has to scroll to the end of the logging\, each and every time. \r\n\r\nDefaulting to the bottom of the first failed step would save many many hours of developer time.
I created a workflow with a workflow_dispatch event\, but the Run Workflow button doesn't show.\r\n\r\nhttps://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/
I want to be able to have action triggered by a human.\r\n\r\nFor example\, an action I have to do often: \Release a new version\".\r\nIt should:\r\n1. create a git tag\r\n2. create a default changelog\r\n3. create a github release as draft\r\n4. a human review the release and its changelog and update content if necessary\r\n5. a human then publish the release\r\n\r\nThat's difficult to do currently in a great way because we don't have a way to just create a button that someone can click and that would then trigger the workflow. Instead we have to find some workarounds\
There seem to be long times for action steps to start. Also\, logs do not always show up\, making debugging timeout builds really hard.
I had a bit of trouble getting the runner to display log messages (error\, warning) \,even if they were in the correct annotation format\, when running in a docker container.
The collapsable parts of the log file take a long time to open\, even after running is completed. When running\, they take SO LONG\, and you can't even view the raw log while running\, so you're forced to wait. Also\, you can't rerun a specific job of a workflow\, which is crazy. That would be my #1 priority. Additionally\, Swift doesn't have great first-party support\, but I understand that. It would also be nice if there were older versions of macOS available\, or at least Xcode versions back to Xcode 10.0. Overall\, though\, GitHub Actions are pretty good\, and I've seen a significant speed increase over Travis CI (my previous platform of choice)
Ability to have manually triggered builds.\r\nAbility to only store the latest N GB of build artifacts from CI (as opposed to specific releases and such that may want permanent storage).\r\nUI used to view in progress builds/logs is pretty unresponsive often.\r\nLack of documentation around formatting logs to nicely show up in groups.
It's painful to attempt to scroll through long logs because you send small chunks! Also please support yaml anchors!\r\n
Hosted runner capabilities: I'd like to use those\, but I wanted to use them like I usually do with other workers: on a kubernetes cluster with autoscalling on nodes and on runner. I'd like to also have the option for single build hosted runner ( runner are destroyed after a single build)\r\n\r\nUI is not great when it come to read logs / search issue ...  workflow may be better ordered by branches sometime.  Read logs should be easier but I've no idea how to ;) \r\n\r\n\r\nA last thing :  The default timeout is 6h. Is it possible to set it up at organization level to 1h for instance? It will force people to set a real timeout when your build are big.
I've used Travis\, Solano\, CircleCI\, and Google Cloud Build.  GitHub actions has been consistently better than most of these in terms of cost\, performance\, and ease of integration into my codebse.\r\n\r\nMy current pain points:\r\n - Random transient failures in GitHub Actions itself.  I've seen stalls during different build steps that are unrelated to the code I'm running.\r\n - Extracting test results to better show why a build failed would be really nice.  Currently I have to scroll through an enormous log file.\r\n - My action yml is very large because of repetitive blocks between different jobs (e.g. a job for compile\, a job for test\, and a job for static analysis).  Each needs the same setup\, like configuring credentials.  It would be nice to have reusable elements.\r\n - I have 2 different yml files\, one for pull requests (compile\, test\, static analysis) and another for master branch (deploy).  There is a lot of redundancy between these\, and sharing somehow would be nice.\r\n - I have package registry artifacts set up for another repo owned by the same organization.  Pulling the artifacts from another repo is painful.  I have to create a personal access token.\r\n - Building a macOS app is very painful with code signing.  This is partially an Apple issue\, but it would be nice to have some help from GitHub on this.
Viewing logs from running workflows should be improved. Currently lines are not flushed until they end (for example to show progress on a single line) and opening a running workflow doesn't show any log until a new line is written.
Like in the build log view it should automatically show the last few lines instead of the first ones.\r\nAlso there is still the problem with error message parsing:\r\nhttps://github.com/Trass3r/bleeding-edge-toolchain/actions/runs/151100840\r\nShows '.github#L9' as filename
It would be really nice to be able to have artifacts which remain in their original format (e.g. `apk` files for android apps which are NOT zip'ed again during download). And even allow non-loggedin github users to download them. This way it's easy to allow users to download snapshot builds.
Deleting Run History Logs
1. If I click on a step when the workflow is in running state\, it is NOT showing logs and getting stuck.\r\n2. self hosted runner is getting disconnected when a newer version of action-runner is available. If says \Updating...\" and run.sh is getting killed."
Actions should run with OR logic from triggers -- that's to say\, if a PR is opened in a repo\, and a commit is pushed\, it should trigger on push OR pull request\, not push AND pull request.\r\n\r\nAdditionally\, it would be cool if there was an option to have options for containerized runners\, instead of VM-based\, a-la CircleCI\, in order to minimize startup time.\r\n\r\nAlso\, there should be a way to make a status badge dependent on a build artifact\, instead of just \succeeded\" or \"failed\"\
It would be nice to be able to access logs for previously failed runs after we re-run them to success. The error message might have useful info for keeping the project working well.
Logs display could be improved.\r\nExample: I made a commit. Soon after build started I open it in browser and cannot see logs of the current step\, only new logs that appear in the step can be seen.\r\nWould appreciate if it will be fixed.
Scrolling the log view is not working well\, at least on Safari Version 13.1.1 (15609.2.9.1.2). The focus hides the scroll bar and it's hard to scroll to the bottom.
2 clicks to get to the failing logs is too many\, make the red x just go straight to the first error.\r\n\r\nI use nix\, but the nix integration isn't up to date so you have to update it manually. Better integration there would be awesome.
I'm having trouble buidling certain packages on the macos runner.  The problem is a python package build (regtex) fails using clang\, because clang can't find stdio.h.  On my own mac I would use `xcode-select --install` to install the XCode Command-Line Tools\, but this opens a GUI dialog\, so it's hard to automate via the command-line.\r\n\r\nIt would be cool if your macos image would have the XCode Command-Line Tools already installed.
- log views are slow and the limited height makes it hard to see what went wrong\, especially with long jobs\r\n- code reuse is hard\, e.g build 10 docker images in a mono repo is a lot of the same code
- currently logs are not enough to debug failed builds\, so there needs to be a better way (i.e. SSH into build containers? an accurate way of simulating builds on a local machine?)\r\n- would also be great to be able to use a private Docker container as the build container\, or at the very least one that is hosted on GitHub Packages
There is still a bug where sometimes clicking the \expand\" arrow on action step output while that step is running doesn't reliably show me what is going on. I really need those live logs!"
very tough to navigate to see the logs of last build
The log often fail to load correctly - especially when inspecting a currently running build.
No manual run for workflows! It's need to be in CI/CD.\r\nI can't run workflow by cron on non default branch!\r\nI can't temporarily disable job in workflow by *click*\, I need to comment out in workflows code and commit it - awful!\r\nWorkflow logs are not displayed in real time. I only see it when the job is done.
I think Actions works great overall\, and I definitely prefer it over the alternatives I've tried (which is mainly Travis). Still I think there's room for improvement. Here's a couple of things that I often walk into:\r\n\r\n* The UI can be slow and become unresponsive\, especially with large logs (>5000 lines). I have to reload the page\, but now the first part of the log is gone\, which can be annoying if all you're really waiting for is one specific test to pass and you can't see its result anymore because it's already been run.\r\n* Sometimes you realize that you've committed some wrong code only after you've pushed it. If you fix your mistake and push again\, most of the time the actions running for the previous commit will not be of interest to me\, and I'd like to have an easy way to kill all workflows for that commit.
Look at Gitlab \u2014 their CI is amazing. Github hosted runner support is pretty terrible and rudimentary in comparison. Would like to see the name of the runner being executed without having to add a custom step to output the name. No way to manually trigger a build pipeline on the web to fire off a custom manual build pipeline. Notifications for failed builds are nigh impossible to output and I've given up trying. Mac shared runner time is 10x shared minutes and only provides a dual-core mac?? How this is acceptable for the amount of resources Xcode builds consume is beyond me\, essentially forcing anyone except those with hobby projects to provision their own mac at Macstadium.\r\n\r\nThe amount of time spent on github actions ongoing maintenance vs gitlab CI has increased 5x since migrating over.\r\n\r\nThe only thing superior to Gitlab is the cache key logic\, allowing us to cache based on a specific condition within the repository. Gitlab only allows you cache keys based on git properties such as branch.
GitHub Actions is great. Thanks for providing a great service for free to open source projects! Three areas of improvement that would benefit me are: (1) Provide CentOS runners\, (2) allow one workflow to depend upon another\, and (3) for large jobs output of the log is often delayed and it seems like the job is stuck.
Actions are still missing a few features to be considered mature\, but its a fantastic product going in the right direction.\r\n\r\n* Using private actions could be a smoother process\r\n* The UI/logs can be flaky and sometimes be out of sync or not appear\r\n* Triggering jobs in other wrokflows without repo_dispatch would be nice\r\n* Some others I can't remember\r\n\r\nMore docs are needed\, I suppose this will come with time.
I've literally spent all week debugging the same action\, in large part because I can't shell into the container and inspect its state. Frequently\, the actions UI doesn't even respond when I try to open parts of the logs -- so my workarounds to attempt to open a live connection to a job in progress using webtty have been unsuccessful (I literally can't read the logs of a running job to get a connection key output by the webtty process).\r\n\r\nI'm moving all of this automation to Circle as soon as I have the time. It's not a great service\, but at least it consistently gives me the information and access I need to figure out how to make my builds work in its ecosystem. 
We have been early adopters of GitHub Actions and hosted runners and have a lot of feedback to provide. For context\, our repository is (or rather used to be) quite large: 700k+ lines of TypeScript code.\r\n\r\nWe have a lot of great things to say about GitHub Actions\, and would recommend it for small repositories. However we do have issues with the service. Let's break them down:\r\n\r\n- It is particularly difficult to define dynamic workflows. Our use case is that of a monorepo\, where testing each package should be in its own job in order to parallelise the work. Currently this cannot be expressed with GitHub Actions: developers must edit and maintain the workflow file themselves. This involves a lot of copy/paste\, and is hence error-prone.\r\n- Similarly\, it is difficult to define variants of a workflow. Say we want to build and test the code on pull requests\, and do the same with also a deploy on a push to master. Currently\, to avoid copy/pasting\, GitHub Actions forces us to define a unique action and conditionally run the deployment according to the triggering event. The config file ends up being quite bloated with some bespoke logic.\r\n- Artifact quotas are cumbersome to manage. We would like to have the ability to automatically cleanup some artifacts after a CI run. Currently we rely on a third-party action that will cleanup old artifacts every 4 hours\, and it often fails. We feel like this capability should be provided by GitHub. It could be as an action that would run as part of a cleanup job at the end of a workflow\, or as a part of the action downloading an artifact\, marking it as \ephemeral\".\r\n- It is difficult to automatically cancel workflows that are redundant. Say we have a workflow to run tests on a pull request\
Thanks for the awesome GitHub Actions product\, we are actively using it\, and have some problems:\r\n1. The hosted runner is not extensible\, not support auto-scaling feature\, dockerized (run them in k8s!)\, etc.\r\n2. The build log is not real-time\, and we cannot watch the log of an unfinished step\, only when it finished can we watch its log.\r\n3. It's very hard to guess which agent the job is running on\, so debugging is harder.\r\n4. We can't re-run a failed sub-job\, we can only re-run the whole job\, which costs much more wasted time.\r\n\r\nEmail: senorsen.zhang@gmail.com
When searching logs if there is only one match you can't navigate to it\, you have to view the raw log and search that.\r\n\r\nI'd like to be able to start a deployment manually or with an API so non-technical team members can publish.\r\n\r\nThe versions of actions should be auto updated with dependabot. Otherwise it's a huge time sync to go find out which ones have new versions.
For self-hosted jobs\, it would be nice to have an option to make a fallback to regular runners if possible or not mark a job as failing if a fork doesn't have a self-hosted runner\r\n\r\nIt would be better to be able to stop or cancel multiple jobs at once\r\nIt would be nice to have instant feedback of a canceled job or job cancelation in progress either in the job or in the overview UI other than just a pop up banner that has no information so I do not try to cancel the same job twice if I lost which job I was at when I was trying to cancel a PR's job or commit's job\r\n\r\nIt would be good to have either rolling builds or something similar so I do not have stale jobs running for old commits or force pushed branches\r\n\r\nSometimes\, when trying to open some logs\, it will either glitch out and say error fetching logs.\r\n\r\nIt would be helpful to have an option to completely expand the log without needing to scroll\, especially on mobile\, plus it would help with the ability to copy and paste from the log rather than needing to open the raw log and then finding the same line and then copying and pasting since trying to highlight a large section while scrolling down will only move the highlighted section and not keep highlighting the new section.
The UI is super slow to load logs from actions that run. It's also a pain to navigate through the different UI pains. 
Missing interactive pipelines (should be simple to trigger by the UI)\r\nCannot re-run single jobs (can only re-run the whole workflow)\r\nLog output is slow and overloads browser (cannot even load sometimes)\r\n 
I can't get my UI tests to run because your hosted Mac runners throw up a dialog: https://github.community/t/macos-runners-all-use-the-same-sharing-name-causing-xcode-ui-tests-to-fail/18180/1
It's often really hard to get logs from a running step.\r\nIt would be great to be able to re-run a workflow from a certain point\, or even just a given job.
want multi-language (eg other than Node) support when building runners; want a sane way to put logs in our standard system (eg a 'log fetch' API or 'log push' action)
No way to manually trigger a build.  Silly.  I should be able to choose a branch and run a single build at a specific commit.  This is how atlassian does it.\r\nNo way to pass configuration params to a build via a gui on the website.\r\nGetting 404 error trying to cancel a build.  This issue is new this week!\r\nNo way to flush/cancel all queued builds - time is money. Perhaps add a \prioritize this build next option.\r\nNo easy way to have multiple runners at 1 ip address...  This is a problem for using 1 VM in Azure to run multiple jobs concurrently.\r\nBuild log viewer is so damn slow and doesn't look right a lot of the time (logs are chopped off and you can't scroll further).\r\nGithub hosted builds are too slow.\r\nGeneral lack of features to make things faster and easier\r\n"
I posted a security vulnerability regarding logs being potentially parseable by non-contributors. I asked for more transparency into who can see CI/CD logs\, and also\, separately\, asked for this to be configurable within the repository settings. While we don't make a practice of echoing secrets\, there's always a chance that these could be inadvertently or maliciously made to leak into the logs.
Central dashboards for actions would be great. \r\n\r\nDocumentation also isn't specific enough and sometimes details that matter for advanced use cases is missing.\r\n\r\nPerformance and UX for the logs screen needs improvement. I click to unfold and my browser frequently crashes or hangs and I'm not sure if the click is even registered. Then I click again to check and it unfolds and refolds a few moments later because of the two clicks.\r\n\r\nShared secrets would save me a huge amount of time and UX pain.\r\n\r\nBetter test case management would be excellent!\r\n\r\nBetter integration into GitHub Desktop would also be excellent and time saving.
I just started so maybe I'm stupid but I'm not able to get logs of my running npm test. It's stuck for some time (and I think it's because there is no Chrome installed on the runner) but it doesn't show any logs.
Love the seamless integration\, but it's really hard to see what goes wrong as I have to scroll through logs that are sometimes nested deeply. It would also be very nice to be able to manually trigger an action!
long loading times of logging output can be anoying
I'm coming from GitLab. Logs don't seem to load when using Safari. Had to switch to a different browser to view.
It would be nice to include the commit message into the email notification about a workflow triggered by a commit. I case of a failure\, it would be nice to include several lines of the runner's log into this message.
hanged docker build log was not available until I stopped the task manually
We use actions for continuous integration. Other CI platforms have an option to automatically cancel in-progress builds for a particular branch if new changes are pushed. This would be nice to have\, as there is no reason to continue building the outdated branch.\r\n\r\nIt would be nice to have an easier way to see test failures in the build. Right now the only way we've been able to do this is with test artifacts which is a clumsy way to see this information.\r\n\r\nThere also seems to be some intermittent flakiness with build output. Sometimes it doesn't let me see the logs for a particular step while it's running.
Dealing with different C++ compilers has very little support. Would be nice with some workflows that makes it easier to have builds for different compilers. At least major versions of Clang and GCC (on the linux builds\, obviously - Windows is limited to MSVCrap and Mac is limited to Clang)\r\n\r\nHuge plus for the general ease of use. seeing where stuff goes wrong in the build is a MASSIVE upgrade from Travis and Appveyor\, where it just dumps all the logs. 
Cons:\r\n- Logs take a while to show up\r\n- Not able to restart workflow if there's an internal failure\r\nPros:\r\n- Running up to 60 parallel jobs is super awesome\, exactly what we needed\r\n- Network speed to GH Packages is really good (we use docker images a lot)
Would be great to:\r\n1. fix Actions and PR pages to keep in-sync with updates in GH\, currently they often loose the sync and need to be reloade\r\n2. extract error-level logs and failed tests (for common test runners) from runs and allow them to be expanded and viewed directly on Actions\, PR\, and action pages
When trying to use Actions as a test runner\, viewing logs (specifically for failed tests) is time consuming. The results of each build step stream in slowly. Compared to competitors with a CI focus\, the user experience is poor.
The documentation seems to be there\, but the writing style makes it difficult to consume. I find myself needing to seek out blogs who lay out usage more clearly.
Good work\, everyone. Stuff that I think is missing:\r\n- workflow dependencies\r\n  e.g. no point in running integration-tests workflow\, if the build workflow fails.\r\n  also e.g. be able to pass the binary generated by workflow A to workflow B\r\n- early quit a workflow: right now the only way to skip a workflow is to `exit 1` (or similar) in one of the steps. But that marks the workflow as \failed\". It should be possible to say \"hmm according to my logic the rest of this workflow is not needed\
* documentation is okay but it could be a bit better. atm i think finding things is kind of hard cuz information seems spread across several different pages.\r\n* expanding the Github action logs sometimes takes ages to load\, and the scroll behaviour seems inconsistent too\r\n* when a push triggers a new job while an existing push job is already running\, the existing push should be cancelled and the new job should start immediately. this would save so much time and unnecessary processing.\r\n
It shows that build fails\, but under the log I see only \We are currently unable to download the log. Please try again later.\"\
Actions don't consistently complete.\r\n\r\nTailing the log often does not work in the UI\r\n\r\n
I spent a long time debugging the whole Github API token nonsense\, since failures manifest in weird ways and the logs are difficult to navigate.  I shouldn't have to jump through extra hoops to make Github actions work with the Github API.
It would be very helpful if we can watch the logs as the steps run. For some reason I can only expand the category once the step is complete. 
It's unstable as hell.\r\n* Things that finish in 1-2 seconds sometimes stuck and time skyrockets to minute or two\r\n* log viewer is broken beyond recognition\r\n - search doesn't work\r\n - frequently can't load logs\r\n - scroll UX is nightmare
Performance of the job logs viewer really needs to be improved. That's my biggest gripe so far.
The live console doesn't work very well. Often it shows no logs until you refresh\, sometimes build steps never display as finished until you refresh. It would be nice to be able to make self-hosted runners spawn a new docker container for each build
Logs are terrible right now compared to other CI providers. I am unable to view logs for a job in progress\, they only show up in realtime. And more importantly\, when job fails\, I have to scroll all the way to the bottom each time which takes forever on some builds. It should autoscroll to the bottom for me.
When I get an error\, sometimes log files are written to the runner\, but I have no way to access those log files to see what went wrong. Otherwise I am really liking github actions \ud83d\udc4d\ud83d\udc4d
Right now\, workflows are very limited in defining when to trigger the workflow. I would like it to allow any logical expression to define when to trigger the workflow.\r\n\r\nFor example\, I want to trigger a workflow when it is a (push on master OR dev branch) AND (the set of files changed are not contained in paths-ignore) AND (at least one file is in the a given set of files).\r\n\r\nRight now\, it is not possible to do arbitrary combination of AND\, OR\, NOT on the conditions that can trigger a workflow.
Logs experience is very bad right now. When it does the intended thing\, it's great. But that doesn't happen often. The main issue is opening and closing whatever the toggle is called for each section. There's very high latency (O(seconds) sometimes) and then you think nothing happened so you click around and the whole window can become unusable because things are just opening/closing on delay...
One issue I encountered is that the chronological ordering of outputs across different streams is not always preserved (e.g. if a build is spitting out a lot of data to stdout\, then encounters an exception that's logged to stderr\, the stderr output is lost among stdout lines despite being the last output).
- UI dropdown toggles to view logs are laggy to the point of approaching nonfunctional.\r\n- UI views seem inconsistent? Sometimes my Actions tab includes external CI statuses like Travis\, sometimes not...\r\n- Action trigger/enablement settings/dependencies are not clear -- sometimes a PR with a new Github action actually triggers the proposed Action to run\, and sometimes it doesn't... and I don't see any clear explanation why one \works\" and not the other.\r\n\r\n- Development: One of the eternal challenges with CI workflow development is feedback time and reproducability for debugging. Any kind of development support to remediate these challenges would be immensely appreciated\
- there's a bug with the PR paths filter where it seems to count files even if they were part of a rebase\, so you end up with irrelevant builds being run.  please get in touch and I can provide more details.\r\n- it's super annoying how many clicks it takes to get to the actual failing part of the build logs
Down times started to be quite frequent lately\, our organization is using Actions for two months now and it already seems much more unstable compared to our last self-hosted CI/CD solution so far. \r\nThe inability to re-trigger a job after an instability is annoying.\r\nSometimes running build logs get stuck with heavy logs and we can't see what is happening in real time.\r\nThe lack of shared workflows among multiple repos was also a painful experience for me personally. When we did our migration to Actions\, I had to create similar and even identical workflows for every repo we had\, one by one. There is also steps that are shared among almost all our Actions and if we ever need to change a single parameter in these steps\, we'll have to do one by one\, again. I'm aware that maybe I could've created a action and shared using the marketplace but honestly it didn't seem easy enough with the time I had.\r\nThe lack of community documentation to resolve specific problems isn't exactly a problem because the official documentation is good enough but that would be also nice\, as it normally speeds up things.\r\nThe drop on allowed minutes per team on Actions\, although said in good advance\, is huge. Our team doesn't even use 3k minutes p/ month yet but the fact that one of the reasons we came to GitHub Actions was the price and scalability\, and just after we joined it is announced a huge time drop that could caught us off guard have we been bigger\, raised a big red flag.\r\nThe product is good but these issues made us dissatisfied lately.
https://ryanprater.com/blog/how-to-set-up-a-cicd-pipeline-with-github-actions
The performance of the log viewer in the browser is unfortunately horrible. The browser takes all the CPU and is still unresponsive sometimes. While a job is running I have to keep in mind to close the Github Actions Tab to not freeze Safari.
Viewing the logs is not entirely reliable. Sometimes the log displays live as the action is running\, and sometimes not. It's oddly intermittent. Searching the log is difficult. Copying-and-pasting from the log includes the line numbers\, which I then have to manually delete\, which is tedious.
The logs are hidden deep within multiple clicks. Also\, discoverability of actions and their parameters is low. Please look at Bitrise Workflow Editor as an example of a nice GUI that helps with discovery. https://github.com/bitrise-io/bitrise-workflow-editor
Sometimes I try to expand a step in build by clicking on it\, and it takes over 30 seconds before any log content for that job is displayed.
i swear to god i cannot tell why npm test is hanging please let us see the logs
There are times when I cannot access the logs when running. The step simply refuses to open. There are also times when the logs stop updating and require a refresh.\r\n\r\nIt's also kind of inconvenient when I have two sequential jobs and I must run both of them even if the first one was successful.
All the experience of GitHub actions is top notch but the logging. It takes several seconds between opening a log group and getting the logs to display.\r\n\r\nNonetheless\, GitHub Actions is the best tool for our team. Awesome job\, guys \u2764
the UI for viewing logs is... not great. sometimes it seems like it just doesn't expand to show the logs\, and it is generally not very responsive. if i click the dropdown\, i expect the logs to appear\, or at least the arrow to move so it looks expanded. and if there's a reason i can't expand it\, i should be given an error message explaining why.\r\n\r\ni should be able to restart builds even if they have all passed.\r\ni should be able to test github actions locally without pushing (saves you money too!)\r\ni should be able to restart a single failed job instead of all of them if one fails.\r\n
Trigger manual builds with a button.\r\nOpening logs can be extremely slow
1) Scrolling and interacting with logs while an action is running is very unusable.\r\n2) It feels like my machine is being used to offload some sort of computation while I'm sitting on the logs to view the action...
- CI skip :) \r\n- Being able to re-use structures across repos\r\n\r\nBoth these issues have been logged by others and are in the trackers.
Github Actions is a killer idea.\r\n\r\nI feel there is still plenty of room for documentation of common cases\, official tools\, configuration wizards\, etc. I find myself digging into obscure blogposts far too often\, to accomplish things that are surely very basic and common scenarios. Many times\, solutions feel too hackish.\r\n\r\nAlso\, I'm very confused about artifact management and more specifically quotas. I was intending to use them to store built apks to each commit (since it seems I can't on a PR level) for testers\, but I hit the quota in a few days. No clue how to deal with that.
Not terribly important\, but maybe something like CircleCI manual triggers would be cool - https://circleci.com/blog/manual-job-approval-and-scheduled-workflow-runs/\r\n
This is minor but it takes a surprising number of clicks to get from the PR page of a running build to the actual contents of the build log (even if I click the yellow icon for a running build\, I then have to open up the actual workflow that's running) -- and then\, when a given step is in progress\, I often can't actually expand that step to see the log content live\, so if something is hung or running slow I won't be able to see it until Actions eventually gives up on it. This is the one usability thing that's a big step backwards from Travis\, which despite its many issues did make it pretty easy to see the log of a job as it runs.\r\n\r\nAlso\, I was surprised that there's no native support for private submodules within our organization (we had to jury-rig a solution involving storing an SSH key in the secrets). Seemed like an oversight.\r\n\r\nOh\, and it sucks that I can't make multiple jobs within one workflow happen conditionally & in sequence -- like\, I'd like to have a workflow that runs 'test' in PRs or in master\, *then* runs deploy if it's in master and the tests succeed (but stops if the tests fail!)\, and *only* runs deploy if it's a staging or prod tag. I couldn't figure out how to do that (the test and deploy would kick off simultaneously for master builds)\, so instead I had to make three different\, mainly redundant workflow files.
1. Realtime logs are usually bugging: freezing and stuck.\r\n2. Database/redis/mongo/etc containers should be up every time - additional time  
I think as it is a emerging technology\, resources are sparse on it just due to it being new and I think that will get better over time.\r\n\r\nThere's still a lot of actions in the GitHub Marketplace that are using the HCL syntax from the first beta. I thought I remembered seeing an email saying those were going to be removed unless they supported the new syntax\, but I could see it as a point people could get stuck on.
I just started using now and I had the few problems:\r\n - Long logs scroll very slow (find works even slower). Raw log is the solution for it;\r\n - Seems slower than travis (at least my tests fail more often because of slow speed... but it's my problem after all and I'll have to tune the tests)\r\n - Documentation could be better (could not figure out how to reuse mvn install in next job... I could use `needs: build` to wait for the first install... but then how to reuse the artifacts)
Cancelling a workflow is often slow: it takes a long time before the run is actually cancelled.\r\n\r\nWhen the matrix data is complex (i.e. an entry in the matrix contains 3 or more fields) then the matrix result is hard to read in the UI.\r\n\r\nUI could be faster/more responsive.\r\n\r\nSearch doesn't work that well when there are many steps. The search bar is at the top of the page. If the step -- that contains the logs that I want to search -- is further down the page\, then when browsing the logs I can't click on the search bar's previous/next button anymore.
Please automatically open the log viewer and scroll the the end for failed steps!\r\n\r\nAlso\, consider open-sourcing the log viewer library\, there aren't many good ones out there.
Opening huge logs in failed builds crashes Safari.
One UX glitch: When deleting an artifact the page shows `No artifacts were generated.` but  it had been generated and the workflow logs also displays that. Maybe the UI should show that there had been an artifact\, nut has been deleted.
YOUR WORKFLOW LOG VIEWER SPIKES MY CPU AT 1000%. WTF! I couldn't even close the dang browser tab.
For long logs\, takes a lot to open and navigate.\r\nSupport for Unity3D\, there's an unofficial action that is pretty immature.\r\n\r\nBesides that\, amazing work! Super excited to transition to Actions from Jenkins/AWS.
==English==\r\n{{wikipedia}}\r\n\r\n===Etymology===\r\nFrom {{m|en|outer}} + {{m|en|space}}.\r\n\r\n===Pronunciation===\r\n* {{a|US}} {{IPA|en|/\u02cca\u028at\u025a \u02c8spe\u026as/|[\u02cca\u028a\u032f\u027e\u025a \u02c8spe\u026a\u032fs]}}\r\n\r\n===Noun===\r\n{{en-noun|-}}\r\n\r\n# Region outside explored space.\r\n# Any [[region]] of space beyond limits determined with reference to boundaries of a [[celestial]] system or body\, especially the region of space immediately beyond Earth's [[atmosphere]].\r\n# A bluish shade of black.\r\n#: {{color panel|outer space ([[w:Pantone|Pantone]])|452f3c}}\r\n#: {{color panel|outer space ([[w:Crayola|Crayola]])|414a4c}}\r\n\r\n====Translations====\r\n{{trans-top|region}}\r\n* Arabic: {{t|ar|\u0641\u064e\u0636\u064e\u0627\u0621 \u062e\u064e\u0627\u0631\u0650\u062c\u0650\u064a\u0651}}\r\n* Bashkir: {{t|ba|\u0439\u044b\u04bb\u0430\u043d|sc=Cyrl}}\r\n* Belarusian: {{t|be|\u043a\u0430\u0441\u043c\u0456\u0301\u0447\u043d\u0430\u044f \u043f\u0440\u0430\u0441\u0442\u043e\u0301\u0440\u0430|f}}\, {{t|be|\u043a\u043e\u0301\u0441\u043c\u0430\u0441|m}}\r\n* Bulgarian: {{t|bg|\u043a\u043e\u0441\u043c\u0438\u0301\u0447\u0435\u0441\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e|n}}\, {{t+|bg|\u043a\u043e\u0301\u0441\u043c\u043e\u0441|m}}\r\n* Catalan: {{t+|ca|espai exterior}}\r\n* Chinese:\r\n*: Mandarin: {{t+|cmn|\u592a\u7a7a|tr=t\u00e0ik\u014dng}}\, {{t+|cmn|\u5b87\u5b99\u7a7a\u9593}}\, {{t+|cmn|\u5b87\u5b99\u7a7a\u95f4|tr=y\u01d4zh\u00f2u k\u014dngji\u0101n}}\, {{t+|cmn|\u5916\u5c64\u7a7a\u9593}}\, {{t+|cmn|\u5916\u5c42\u7a7a\u95f4|tr=w\u00e0ic\u00e9ng k\u014dngji\u0101n}}\r\n* Dutch: {{t+|nl|ruimte|f}}\r\n* Finnish: {{t|fi|ulkoavaruus}}\r\n* French: {{t|fr|espace cosmique|m}}\, {{t+|fr|cosmos|m}}\r\n* German: {{t+|de|Weltraum|m}}\, {{t+|de|All|n}}\, {{t+|de|Weltall|n}}\r\n* Gujarati: {{t|gu|\u0a85\u0a82\u0aa4\u0ab0\u0abf\u0a95\u0acd\u0ab7}}\r\n* Hebrew: {{t|he|\u05d4\u05d7\u05dc\u05dc \u05d4\u05d7\u05d9\u05e6\u05d5\u05df|tr=hakhal\u00e1l hakhitz\u00f3n}}\r\n* Hindi: {{t-needed|hi}}\r\n* Icelandic: {{t|is|\u00fatgeimur|m}}\r\n* Italian: {{t|it|spazio cosmico|m}}\, {{t+|it|cosmo|m}}\, {{t|it|spazio esterno|m}}\r\n* Japanese: {{t+|ja|\u5b87\u5b99|tr=[[\u3046\u3061\u3085\u3046]]\, uch\u016b}}\, {{t|ja|\u5b87\u5b99\u7a7a\u9593|tr=\u3046\u3061\u3085\u3046\u304f\u3046\u304b\u3093\, uch\u016bk\u016bkan}}\r\n* Korean: {{t+|ko|\uc6b0\uc8fc}}\r\n{{trans-mid}}\r\n* Macedonian: {{t|mk|\u0432\u0441\u0435\u043b\u0435\u043d\u0441\u043a\u0438 \u043f\u0440\u043e\u0441\u0442\u043e\u0440|m|sc=Cyrl}}\r\n* Malay: {{t|ms|angkasa lepas}}\r\n* Maori: {{t|mi|tuarangi}}\r\n* Navajo: {{t|nv|y\u00e1gh\u00e1honik\u00e1\u00e1n}}\, {{t|nv|y\u00e1gh\u00e1hook\u00e1\u00e1n}}\, {{t|nv|y\u00e1hon\u00edk\u00e1\u00e1n}}{ config\, lib\, ... }:\r\n\r\nwith lib;{ config\, lib\, ... }:\r\n\r\nwith lib;\r\n{\r\n  options = {\r\n    appstream.enable = mkOption {\r\n      type = types.bool;\r\n      default = true;\r\n      description = ''\r\n        Whether to install files to support the \r\n        <link xlink:href=\https://www.freedesktop.org/software/appstream/docs/index.html\">AppStream metadata specification</link>.\r\n      '';\r\n    };\r\n  };\r\n\r\n  config = mkIf config.appstream.enable {\r\n    environment.pathsToLink = [ \r\n      # per component metadata\r\n      \"/share/metainfo\" \r\n      # legacy path for above\r\n      \"/share/appdata\" \r\n    ];o.paypal.monero.venmo.bitcoin.ripple.venmo.hsbc.nylas.tether.chikitaisaac1982.wikipedia.api**Www.Chikitaisaac123@gmail.com www.coinbase.bitcoin.paypal.monero.bitcoin.venmo.varo.bitcoin.venmo.varo.jetcoin.venmo.chikitaisaac1982.wikipedia.varo.venmo.hsbc.waleteros.acorn.jetcoin.robinhood.acorn.tether.googledoodle2099waleteros.hsbc.venmo.paypal.googledoodlebitcoin.com2099.nylas.chikitaisaac1982.wikipedia.bitco"
Log viewer is very slow\, logs don't show up in a reasonable amount of time when a workflow is running and has no history until the step is finished.\r\n\r\nYAML workflow files don't support anchors.
Github actions can remain queued for a long time! Mine was created 7 hours ago and it's still queued!\r\n\r\nhttps://github.com/nodejs/node/actions/runs/79125900\r\n\r\nAlso\, searching the logs is completely useless\, because it doesn't jump to the search result. I always go right for the raw logs. The browser is at least three orders of magnitude faster at searching the raw log than the fancy highlighting that the Web page tries to do.
the workflows is not available to re-run the flow if is green\, I can't deploy a workflow with custom params from a UI. I can't see the logs live in the log screen
It would be nice to be able to click through to the console/log directly from the Actions tab. Maybe add it to the [...] menu on the list item?
While I love having my CI so close to my repository\, the overall experience feels a bit flaky still: Builds are queued longer than normal seemingly randomly\, logs can sometimes not be seen (the section in the step can't be expanded) or builds fail due to the service (as they work if you retry). 
Logging of actions leaves something to be desired. Would be better if logs could be observed in real time and there was an all actions view.
* congrats! it's been very useful. \r\n* i'd love to have a unified view of all my builds (and their statues) in a single place \r\n* please provide some buttons to scroll instantaneously to the bottom of the log output and to tail the log output.\r\n
- The macOS runner is unstable (slowdowns\, unable to start).\r\n- Please add support for colors in logs (it's way easier to debug a failed build when the error is shown in red)
Can we remove old logs ?
When checking the status of the Actions that are currently running\, sometimes the page freezes and makes that browser Tab stop.\r\nAlso\, I'd like to be able to use the browser's Ctrl+F (find) on the log from the Actions. But it's not currently possible.
I\u2019d like to control who may see the results of builds. In one of my repositories I\u2019d like to make the build artifacts available for everyone (even users who aren\u2019t logged in). In another of my repositories the GitHub Actions is only used for deployment\, so I\u2019d like to make the whole Actions tab private.
Mainly the build logs are harder to use. Per step there's only a little window to scroll in. Some build logs are really long and it's harder to navigate through the entire log everytime
Please improve the logs page. It's very glitchy and small. Especially when the builds are running.
For a running job\, trying to expand the log (by clicking on the step headline with the spinny circle) does nothing\, and results in no UI change.
1. Sometimes I cannot open job logs to debug while In progress. After the finish\, I can view logs\, but I need to check logs also in progress status because sometimes it feels a job like stuck.\r\n\r\n2. It would be nice to add depend_on to another workflow. I have Test workflow and Deploy workflow and I want them to be separate\, but I need to Deploy workflow to depend on Test workflow success status.\r\n\r\n3. Currently\, we have published private packages on GitHub Package Registry\, but GITHUB_TOKEN is only for current repository and I cannot fetch private package from other repository. Would be nice that GITHUB_TOKEN would be Organisation based for Packages. Currently\, for this I need to use my personal token\, which is not nice.\r\n\r\n4. It would be a nice ability to trigger build manually. I saw some people making hacks to build on Star\, then removing Star and starring it again to build\, but would be nice to have a button for that. 
UI for log viewing is hardly usable for big logs.\r\n\r\n* UI cuts long lines\, when I wanted to check if specific compiler flag is actually in\r\nuse\, and of course it was beyond \...\"\r\n* UI doesn't allow using built-in search of browser\
1. Frequently disk space errors\r\n2. Hard to access logs\, very high latency on accessing logs
Regarding debugging\, sometimes when a build is stuck and not producing any output\, it's frustrating when the output log waits for new output before sending any of the previous output.\r\n\r\nRegarding documentation\, I'm just \u2026 never sure where to look for something\, I guess.
The log outputs seem to be very slow and not update regularly enough
The view for scrolling through logs is super cumbersome and doesn't let me easily copy / paste. Also\, if I want to rerun a workflow but I still want access to the previous failed run\, it's unclear to me how to access the failed run. 
There are a few things that really need to be sorted ASAP:\r\n* Ability to abstract away workflows in yml to avoid repetition.\r\n* Add more abilities to self-hosted runners like multiple repositories for runners or easy of starting multiple runner instances on same machines.\r\n* More documentation on use cases - possibly in the form of blog posts.\r\n* Better support - I have sent 2 support requests towards the end of last year. One was ignored\, the other was poorly replied to.
Often I cannot scroll through logs in failed builds\, which makes it very difficult to see what's going on.
Console logs must be printed in reverse order. Something like a \tail\" command. Because build status are mostly at the end of the logs and it will make it easier to check failed and passed status."
I wish I could see live updates on the output from my self-hosted runner.  Right now it looks like I have to wait for the test to complete before I see any logging information.
Important:\r\n- Streamed logs from self hosted runners are flaky.\r\n- Automatic cancellation of stale workflows would be very valuable. We currently use rokroskar/workflow-run-cleanup-action for this.\r\n\r\nNice to have:\r\n- Being able to import yaml from other files into workflows i.e. templating would be helpful.\r\n- We've forked the self-hosted runner in order to support our long-lived build tooling bazel and prevent it being killed after each call. It'd be nice to have a flag for this.\r\n\r\nContact me on peter@baseup.com.au if you have any further questions on the above.
Capturing assets/artifacts produced the build is a tremendous PITA.\r\nI need to use no fewer than 3 different actions for uploading to releases in different contexts.  The uploads are flakey and need retries.\r\nWhile a build can capture an artifact\, it is only accessible to logged in users (which people are reporting as a problem: why should they need to have a github account to download an artifact?)\, and there is no way to link to the most recently successful build from our github pages\, so even if we could provide access to unauthenticated users\, we have no way to reference the build anyway.
Been trialling vs CircleCI and CodeBuild.\r\n\r\nTailing build logs kills my browser. Chrome and Firefox. Really annoying.\r\n\r\nBeing able to run builds locally would save a heap of setup time. I can do this with AWS CodeBuild.\r\n\r\nBetter way to share docker images between build stages. Saving the image as an artifact is slow and limited by DockerHub artefact storage. Using an external docker repo costs bandwidth.\r\n\r\nDocker layer caching built in.
The log view on running actions breaks if there is too much text\, making it difficult to debug steps containing things like \choco install\" as that spams the log with the download progress"
The interface to view a running job is a little unreliable - often when I click to expand one of the jobs so I can see the logs it doesn't expand straight away\, sometimes it only expands once that job is done. I'd like it to be easier and more reliable to watch the logs of my tasks updating as close to real-time as possible.
The output logs aren't very convenient. For example\, to see the results of a unit-test step\, I need to scroll in a tiny window hundreds of lines. It would be nice if there was some way to make that larger
Documentation is poor and very hard to follow. I've been working on trying to get my action working for two business days and it's still not working. I'm mostly relying on google searching for existing configs and then pulling the pieces I need out.\r\n\r\nThe `add-mask` functionality should be listed prominently in the `set-env` documentation. Very frustrating to see my secrets that I pulled in through a 3rd party service\, EnvKey\, exposed in the logs. Now I need to rotate my keys.
Two things that would make actions a whole lot more awesome:\r\n\r\n1. The ability to delete old outdated workflows that I no longer care about.\r\n2. Ability to hack on actions locally without flogging my action history on github (i'm aware of the 3rd party tools for this\, but would be great if github supported officially)
Shared secrets (org-level) would make it _a lot_ easier for us to manage our workflows. Currently\, credentials for e.g. our artefact storage are very hard to rotate\, since we'd have to go into each repo and change the secrets (or setup additional tooling).\r\n\r\nAlso\, we'd love if it would be easier to work with SSH keys on a hosted runner. Currently we rely on our own action (https://github.com/exivity/actions\, similar to https://github.com/webfactory/ssh-agent).\r\n\r\nDebugging a failed workflow is a complex problem I don't have a final answer to\, but solving this would make a huge difference to us (and I guess a lot of others too). We still spend a lot of time solving environment-related problems with trial-and-error (the modify/commit/wait/read log feedback loop). Interacting with the environment directly (either through remote access\, vm snapshots\, breakpoints\, local mirroring\, etc.) would save us some time.
- hard to make rollbacks like in travis: can't run specific tags builds\r\n- can't debug builds like in travis: you have a direct ssh access to play with the build\r\n- log is very slow to appear \r\n- builds list is no refresh realtime so I have to F5 all the time
Most importantly for me: it would be nice if the last run's artifact were never expired.\r\n\r\nSupport has been amazing so far.  It would be nice if I didn't have to download large log files (maybe this has changed).  There were some docs errors but these are probably also fixed by now.
I feel unpleasant for workflow failure due to GitHub/Azure/SQLServer internal errors.\r\nI also met HTTP 422 / HTTP 500 / broken connections when I invoke GitHub REST API (release artifacts).\r\nI ran into 6hrs timeout several times (not GitHub's API)\, I don't know if there is anything can be improved on the network side. I just have to write retry/timeout logic everywhere in my CI code.\r\nJS/TS is first-class language for GitHub Actions\, but there is still room for integrating other script language (Python please).\r\nI wish the document of GitHub Actions can be more clearly organized. (maybe open source your documentation and accept PR) For example\, many new-comers may not know how to set steps.<step_id>.outputs.foo without a JS/TS actions\, although it's as easy as print some strangely encoded string to stdout. And the encoding method itself is undocumented\, oops.\r\n\r\nBut anyway\, thank you for GitHub Actions. I like it and hope it can do better.
- The logs are kinda hard to read when compared with Travis\, the UI often does not respond when expanding a step.\r\n- I'd love to see a mobile UI since right now the desktop version is shown on mobile.\r\n- I've encountered an interesting bug when setting up docker buildx in one step then using it in another. My builder config (docker buildx create --use xxx) gets reset for some reason.\r\n- ARM runners would be sweeeeeet\r\n- I'd love to see an updated Docker version for the ubuntu:latest runners
I would like more tooling and more documentation on triggers and on conditionals. It would be great to have a UI that lets me interactively check off the different triggers I want to use for a workflow\, and let me see some example API context available for each.\r\n\r\nCurrently it also takes effort to figure out different conditionals and ways to chain together jobs. Perhaps more cookbook examples of overall approaches to multi-job workflows (not language specific). If the UI could provide some sample GH API context\, then it would be great to be able to test conditionals and logic in the UI.